Hardening our passwords seems like this
should be an obvious topic or an obvious decision
when it comes to our security posture
and how we protect against threats.
But this is still one of the most common attacks that
are around today because ends users,
and even software developers or IT professionals
still overlook and ignore this threat.
So what we have to do in this particular Nugget
is talk about how passwords are really a vulnerability
and what mitigation steps we can take to harden ourselves
against this problem.
Obviously, if we're going to talk about passwords, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Obviously, if we're going to talk about passwords,
we have to talk about password complexity.
And I recently found this little infographic on Reddit.
Hive systems, I guess, are the people who created this.
I think this is really, really cool
of them to put this little infographic out there
in the wild.
Look at this.
Look at the comparison chart of how complicated
your password can be.
Over here we have the number of characters
going from smallest to largest.
And over here, across the top, across the x-axis,
we have password complexity, so numbers only,
letters only, upper and lower case, number upper and lower WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
letters only, upper and lower case, number upper and lower
case, and then with symbols.
So if I had a 12 character password that
has numbers, uppers, and lowercase,
I see that it can take 2000 years to crack that password.
Throw in one symbol and that becomes 34,000 years.
And this begs the question, how are they
attacking this password in the first place?
Well, there's a bunch of different ways, you see.
And that sets up the discussion about why
this chart is so important.
The first way attacker is going to attack WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The first way attacker is going to attack
a simple password is with something called a dictionary
attack.
In about one Google search, I can scroll down a hair here,
and I see these zip files that contain
huge, huge amounts of passwords that are simply
stored in Excel files, or text documents,
or something like that.
And the idea is that we have an application that
will go through each one of these passwords
and try and log into a website, or log into an application
trying one password at a time.
They're only looking to get in once, that's the key. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
They're only looking to get in once, that's the key.
So a dictionary attack is all about using
a file that contains a dictionary, so to speak,
of nothing but passwords that it can try over, and over,
and over, and over again, as it attempts
to break into the website.
This is why it's so important to change your password.
There's another website that I think is really cool,
have I been pwned?
You can type in your email address right here,
and it will tell you if your email address
and a matching password appears somewhere
in its database or its dictionary of leaked usernames WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in its database or its dictionary of leaked usernames
and passwords.
So there's your mitigation steps to the dictionary attack
right there.
Just see if your email address and password have already
been leaked somewhere.
So if your email address and your password
aren't there out in the wild, then it
comes into this play right here.
The next thing a hacker will try and do
is what's called a brute force attack.
With a brute force attack, it will literally just
start trying random numbers, characters, and so on over,
and over, and over again until it gets in. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and over, and over again until it gets in.
And here's the thing, with a brute force attack,
or even a dictionary attack, it can try dozens, or hundreds,
or if it's powerful enough, thousands
of passwords per second.
But because the number of combinations
when you have this many characters
and this many possible characters
is so tremendous, even with that kind of processing power,
it will still take an absolute tremendous amount of time
for a hacker to brute force their way into passwords. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for a hacker to brute force their way into passwords.
And this is why we have things like password
policies in Active Directory.
The password policies enforce a minimum number
of characters, a specific combination of upper, lower,
number and symbols.
And beyond that, we have to rotate new passwords
in every so many days so that way if a password does get
leaked, by the time it gets around the world,
we've already moved on to a new password.
But this isn't the only way that passwords can be exploited.
Software developers, especially new software developers,
maybe like myself, tend to hard code passwords WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
maybe like myself, tend to hard code passwords
directly in their code.
And when a password is sitting there in plain text,
if a hacker accesses that system,
they can read the document and see what the password is.
But it gets worse.
Now with the advent of source control,
new developers can not only write their code
and hard code the passwords, they
can end up sharing it with the world.
Here's my very own GitHub repo, and here's a document
that I created when I was going through the DevNet
Associate study.
Right here on lines three and four,
you can see I've got the fully qualified domain WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you can see I've got the fully qualified domain
name, the port that it's listening on,
the username, and the password.
And this document is publicly available.
Now I know you're like, whoa, wait a minute.
Don't do that.
This resource is actually deployed publicly available.
Cisco has put this device out there so that anyone
can log into it and use it.
So I'm not breaking any routes or anything by doing this.
But the gist of it is this is a big no-no.
Don't do this.
Don't hard code your usernames and passwords
under any circumstance in your code. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
under any circumstance in your code.
And don't publish that code on top of that.
There are different things that you could use.
First of all, you should use some form of key vault,
like Azure Key Vault. This is a secure way where
your application would have to log in to the key vault,
and then once it's been authenticated,
it can then return the password that it
should use for something like a database, or something
like an application server.
But if you don't have access to this, in a worst case scenario,
you could at least tell your code
to retrieve something like an environment variable out WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to retrieve something like an environment variable out
of the server that it's on.
So you could put your password in an environment variable
in the server.
That way when you publish your code to get GitHub,
you're not publishing the password.
All you're doing is publishing that the password must come
from an environment variable.
The hacker would then have to gain access to the server
and explore the environment variables to find the password.
So again, this is not the best case scenario.
You don't want to use environment variables.
You want to use some sort of resource, or tool,
or application, like a key vault.
But if you absolutely do not have access to those resources, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But if you absolutely do not have access to those resources,
the worst thing you could do is hard
code a username and password and then share it with the world.
Now the last thing, especially is a network administrator
that you have to keep in mind, is default user names
and password.
There is an OK chance that at some point in our career,
we've tried to log into our own home router,
like a Linksys device, or Netgear device,
or an Asus device.
And that's great because, you know,
we're networking professionals and this is kind of our jam.
We want to log in and see it.
But here's the thing.
These devices like this, when you buy them WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
These devices like this, when you buy them
off the shelf at a retailer like Best Buy or something
like that, the average end user is just going to plug it in
and it's just going to work.
And they're never, ever going to log into this device.
Beyond that, when they log into this device,
there's an OK chance that it won't prompt them
to change the default password.
So this device will forever remain
with a user name of admin and a password of admin
So any hacker who attempts to attach to that network,
maybe they're driving by, an attack called wardriving,
where they're driving by their house WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
where they're driving by their house
and they see a wireless access signal,
they could temporarily, potentially connect to it
and then immediately get in to the network device itself.
Now that's in home networking.
Obviously, the same goes for business networking, too.
You never want to use default passwords anywhere.
And not just on network devices, but on servers, IoT devices,
even your battery backups, like UPSes that have NIC cards.
You don't want them to use the default credentials there.
So password protection is a little bit more
than just setting a complicated password. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
than just setting a complicated password.
You also have to keep in wherever
your default passwords may be used in your environment.
We need to update that right away.
And we also need to talk to our security and application
developers, and talk to them about, how are you actually
storing the credentials that the application is going to need?
That's important, too.
So that's been understanding password attacks.
I hope this has been informative for you.
And I'd like to thank you for viewing.